home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
TPUG - Toronto PET Users Group
/
TPUG Users Group CD
/
TPUG Users Group CD.iso
/
CRS
/
crs49.d81
/
hack2-1.sfx
/
hack.1
Wrap
Text File
|
1990-02-12
|
48KB
|
1,001 lines
├├├├├├ ╚╚ ╚╚ ┴┴┴┴ ├├├├├ ╦╦ ╦╦ ╔╔╔╔╔╔ ╬╬ ╬╬ ╟╟╟╟
├├ ==== ╚╚ ╚╚ ┴┴ ┴┴ ├├ ╦╦ ╦╦ ╔╔ ╬╬╬ ╬╬ ╟╟
├├ ==== ╚╚ ╚╚ ┴┴ ┴┴ ├├ ╦╦╦╦ ╔╔ ╬╬ ╬╬╬╬ ╟╟
├├ ╚╚╚╚╚╚╚╚ ┴┴ ┴┴ ├├ ╦╦╦╦ ╔╔ ╬╬ ╬╬╬╬ ╟╟ ╟╟╟
├├ ==== ╚╚ ╚╚ ┴┴┴┴┴┴┴┴ ├├ ╦╦ ╦╦ ╔╔ ╬╬ ╬╬╬ ╟╟ ╟╟
├├ ==== ╚╚ ╚╚ ┴┴ ┴┴ ├├ ╦╦ ╦╦ ╔╔ ╬╬ ╬╬ ╟╟ ╟╟
├├├├├├ ╚╚ ╚╚ ┴┴ ┴┴ ├├├├├ ╦╦ ╦╦ ╔╔╔╔╔╔ ╬╬ ╬╬ ╟╟╟╟╟
╓OLUME 1 - ╔SSUE 2 - ┴PRIL 22, 1992
==============================================================================
┼DITOR'S ╬OTES:
BY ├RAIG ╘AYLOR (DUCK@PEMBVAX1.PEMBROKE.EDU)
┼EEGH! - ╫HEN ╔ FIRST STARTED THIS ╔ NEVER REALIZED HOW MUCH WORK IT'D BE.
╔'M GLAD OF THE RECEPTION IT'S GOTTEN FROM THE ├OMMODORE COMMUNITY AT LARGE. ╔'D
LIKE TO THANK EACH OF THE AUTHOR'S IN THIS ISSUE AND LAST FOR THEIR WORK THEY'VE
PUT INTO IT AS WELL AS THEIR TIME.
╨LEASE NOTE THAT ALL FILES, DOCUMENTATION ETCETERA ASSOCIATED WITH ├= ╚ACKING
AND WHATNOT CONTAINED WITHIN ARE ALSO NOW AVAILABLE AT TYBALT.CALTECH.EDU VIA
ANONYMOUS FTP UNDER THE DIRECTORY /PUB/RKNOP/HACKING.MAG. ┴NY UPDATES TO FILES
CONTAINED WITHIN OR CORRECTIONS WILL BE POSTED THERE AS WELL AS MENTIONED
HERE. ├URRENTLY IT HAS THE CORRECT 1ST ISSUE AND (SOON TO BE) 2ND ISSUE. ┴LSO
╥OBERT ╦NOP'S FILE BMOVER.SFX IS THERE FOR THE ┬ANKING ╟EOS ARTICLE IN THIS
ISSUE.
╔T SEEMS AS IF WE'RE AVERAGING ABOUT 2 MONTHS FOR EACH ISSUE AND HOPEFULLY
WE'LL KEEP THAT RATE DURING THE SUMMER BUT DUE TO AN INTERNSHIP (╔'LL HOPEFULLY
GET) ╔ MAY NOT HAVE NET ACCESS DURING THE SUMMER. ╔N THAT CASE IT'LL BE DELAYED
UNTIL AFTER ╔ GET BACK TO SCHOOL IN THE FALL.
┴LSO, IF YOU'VE GOT ANY IDEAS FOR ARTICLES OR HAVE WRITTEN A PROGRAM THAT IS
UNIQUE THAT YOU'D BE INTERESTED IN DOCUMENTING AND P'HAPS LETTING OTHER PEOPLE
SEE SOME OF THE TRICKS OF THE TRADE THEN PLEASE SEND ANY QUERIES TO
DUCK@PEMBVAX1.PEMBROKE.EDU.
****************** ╫┴╥╬╔╬╟╙, ╒╨─┴╘┼╙, ┬╒╟ ╥┼╨╧╥╘╙, ┼╘├... *********************
╨LEASE NOTE THAT IN THE LAST ISSUE WHEN THE UNDOCUMENTED OPCODES WERE
DISCUSSED THAT THEY ARE _╓┼╥┘ ╬╧╬-╙╘┴╬─┴╥─_. ┴ND ANY FUTURE ACCELERATOR BOARDS
FOR THE ├=128 OR ├=64, IN ALL LIKELEHOOD, _WILL NOT WORK_. ┌IP'S BOARD [WHEN ARE
THEY EVER GONNA FINISH IT?] FOR THE ├=128 WILL BE BASED ON A SIMILAIR PROCESSOR
TO THE 8502 AND IS PRACTICALLY GUARENTEED NOT TO WORK WITH THE UNDOCUMENTED
OP-CODES. ╔F YOU PLAN TO RELEASE ANY ═╠ PROGRAMS FOR GENERAL USE ╨╠┼┴╙┼ BE
AWARE THAT THEY MAY BE IN-COMPATIBLE WITH FUTURE SYSTEMS.
============================================================================
╬OTE: ╨ERMISSION IS GRANTED TO RE-DISTRIBUTE THIS "NET-MAGAZINE", IN WHOLE,
FREELY FOR NON-PROFIT USE. ╚OWEVER, PLEASE CONTACT INDIVIDUAL AUTHORS FOR
PERMISSION TO PUBLISH OR RE-DISTRIBUTE ARTICLES SEPERATELY.
*** ┴╒╘╚╧╥╙ ╠╔╙╘┼─ ┬┼╠╧╫ ╥┼╘┴╔╬ ┴╠╠ ╥╔╟╚╘╙ ╘╧ ╘╚┼╔╥ ┴╥╘╔├╠┼╙ ***
============================================================================
╔N THIS EDITION WE'VE GOT THE FOLLOWING ARTICLES:
╠EARNING ═╠ - ╨ART 2
┘ES, THE INFAMOUS LEARNING MACHINE LANGAUGE TUTORS BY ├RAIG ╘AYLOR
(DUCK@PEMBVAX1.PEMBROKE.EDU). ╔N THIS SESSION WE EXAMINE INDEXED ADDRESSING
AND IT'S USEFULLNESS IN PRINTING STRINGS OF CHARACTERS.
8563 : ┴N ╔N-─EPTH ╠OOK
╘HIS ARTICLE DOCUMENTS AND DETAILS THE 8563 IN-DEPTH. ╔T COVERS ALL
AVAILABLE REGISTERS, DOCUMENTS THEIR FUNCTIONS AND SUGGESTED METHODS OF GETTING
CERTAIN EFFECTS. ┴LSO COVERS HOW TO READ AND WRITE TO 8563 REGISTERS AS WELL
AS READ THE 16K OR 64K OF MEMORY THAT CONTAINS THE ╓─├ CHAR-SET, SCREEN MEMORY
ETC. ╫RITTEN BY ├RAIG ╘AYLOR (DUCK@PEMBVAX1.PEMBROKE.EDU).
╘HE ╨OOR ═AN'S ╫AY TO ╟ETTING ╞ILES FROM ═╙-─OS ─ISKETTES
╬OW THERE'S A WAY TO TRANSFER FILES OF ANY LENGTH FROM ═╙-─OS DISKETTES USING
A PUBLIC DOMAIN PROGRAM THAT WILL ONLY READ FILES OF 43K OR LESS AND A ╔┬═
PROGRAM TO SPLIT THE FILES UP. ╘HERE ARE BETTER WAYS, BUT IF YOU DON'T WANT
TO PAY FOR ┬IG-┬LUE ╥EADER THIS IS ONE METHOD TO GO. ╫RITTEN BY ═ARK ╠AWRENCE
(9152427─@╠EVELS.╒NI╙A.┼DU.┴U).
┬ANKING ON ╟EOS
╟┼╧╙ 128, BEING AN EXTENDED AND EXPANDED VERSION OF ╟┼╧╙ 64, PROVIDES A
CONTIGUOUS BLOCK OF APPLICATION SPACE IN A SINGLE ╥┴═ BANK. ╘HE "STANDARD"
PROGRAMMING DOCUMENTATION MAKES FEW REFERENCES TO THE USE OF OTHER BANKS IN
╟┼╧╙. ╘HIS ARTICLE DESCRIBES ACCESSING OTHER ╥┴═ BANKS (INCLUDING ╥┴═ BANKS 2
AND 3 FOR 256╦ EXPANDED 128'S) UNDER ╟┼╧╙128, USING BOTH THE ╟┼╧╙ ╦ERNAL
ROUTINES AND MORE DIRECT METHODS. ┬Y ╥OBERT ╦NOP (RKNOP@TYBALT.CALTECH.EDU).
─YNAMIC ═EMORY ┴LLOCATION
╫RITTEN BY ├RAIG ┬RUCE (F2RX@JUPITER.SUN.CSD.UNB.CA) THIS ARTICLE EXAMINES
HOW TO IMPLEMENT AND USE DYNAMICALLY ALLOCATED MEMORY THAT WILL ALLOW YOUR
PROGRAMS TO BETTER UTILIZE ALL OF THE AVAILABLE MEMORY ON YOUR ├=128, INCLUDING
EXPANSION MEMORY. ╘HESE ROUTINES ARE EXTRACTED FROM THE ┌ED-128 PROGRAM WHICH
IS A TEXT EDITOR THAT CAN EDIT 600╦┬YTE FILES ON A 512╦ EXPANDED 128.
=============================================================================
┬EGINNING ═╠ #2
BY ├RAIG ╘AYLOR (DUCK@PEMBVAX1.PEMBROKE.EDU)
╠AST TIME WE INTRODUCED THE DEFINITION OF WHAT EXACTLY ═ACHINE ╠ANGUAGE /
┴SSEMBLY ╠ANGUAGE IS ALONG WITH AN EXAMPLE OF CLEARING THE SCREEN IN ═ACHINE
╠ANGUAGE.
╬OW, IN THIS ISSUE LET'S PRINT MY NAME (AND LATER YOUR NAME). ╠OOKING AT THE
CODE FROM LAST TIME THE FOLLOWING ASSEMBLY SOURCE JUMPS TO MIND:
------------
PRINT_1.ASM:
LDA #147 ; CLR/SCREEN CODE
JSR $FFD2 ; PRINT
LDA #'├' ; CODE FOR ASCII "├"
JSR $FFD2 ; PRINT
LDA #'R'
JSR $FFD2
LDA #'A'
JSR $FFD2
LDA #'I'
JSR $FFD2
LDA #'G'
JSR $FFD2
LDA #32 ; CODE FOR SPACE
JSR $FFD2
LDA #'╘' ; PRINT MY LAST NAME....
JSR $FFD2
.
. (AD NASEUM...)
.
RTS
----------
╬OW, FOR SHORT STRINGS LIKE "╚╔!" THAT MIGHT BE FINE BUT IF YOUR NAME IS
SOMETHING LIKE "╙EYMOUR ╩OHNSON THE THIRD" IT CAN GET A LITTLE BIT RIDICULOUS
IN TERMS OF THE AMOUNT OF MEMORY AND THE AMOUNT OF TYPING (EEGH! - TYPING!)
INVOLVED. ╘HERE'S AN EASIER WAY.
╔T'S CALLED INDEXED ADDRESSING. ╫HAT IS THIS YOU SAY? ╠ET'S FIRST TAKE A
LOOK AT THE ABOVE PROGRAM USING INDEXED ADDRESSING AND THEN EXPLAIN IT.
------------
PRINT_2.ASM
LDY #$00
LOOP LDA STRING,Y
JSR $FFD2
INY
CPY #NUMCHARS
BNE LOOP
RTS
STRING .BYTE 147
.ASCII "├RAIG ╘AYLOR"
NUMCHARS = *-STRING
------------
╚MM, LOOKS A LITTLE BIT CONFUSING 'EH?
╫HAT WE'RE DOING IS USING THE REGISTER Y TO ACT AS A POINTER TO GRAB THE
Y'TH CHARACTER IN WHAT IS AT MEMORY LOCATION ╙╘╥╔╬╟. ╔F Y IS 0 THEN WE'LL GET
STRING+0 WHICH HAPPENS TO BE A 147.
╘HE .BYTE AND .ASCII DIRECTIVES ARE NOT REAL INSTRUCTIONS THE COMPUTER
UNDERSTANDS. ╫HAT HAPPENS IS THAT YOUR ASSEMBLER SEES THAT YOU WANT DATA
PUT AT THOSE LOCATIONS SO IT CONVERT 147 AND "├RAIG ╘AYLOR" TO NUMBERS
AND PUTS THEM AT THE PROPER LOCATIONS, RELIEVING YOU THE BURDEN OF DOING IT.
╘HE NUMCHARS = *-STRING LOOKS CONFUSING AT FIRST... OBVIOUSLY, NUMCHARS
STANDS FOR THE NUMBER OF CHARACTERS WE NEED TO PRINT OUT BUT HOW IS IT BEING
FIGURED? ═OST ASSEMBLERS KEEP THE CURRENT LOCATION IN MEMORY IT'S ASSEMBLING
TO IN SOMETHING CALLED A PROGRAM COUNTER OF ╨├. ═OST ASSEMBLERS ALSO WILL LET
YOU HAVE THE VALUE AT ASSEMBLY TIME BY REFERENCING IT USING THE "*" SYMBOL.
"STRING" IS ALREADY A SYMBOL THAT HAS BEEN SET AN ADDRESS IN MEMORY AND AFTER
ASSEMBLING THE .BYTE AND .ASCII INSTRUCTION "*" WILL BE EQUAL TO THE NEXT
ADDRESS THAT THE ASSEMBLER WOULD PUT ANY INSTRUCTIONS AT, HAD WE HAD ANY.
╬OW, *-STRING BASICALLY IS SAYING TO THE COMPILER, LOOK, TAKE THE CURRENT
PROGRAM COUNTER (WHERE IT'S ASSEMBLING TO) AND SUBTRACT IT FROM WHERE THE
SYMBOL STRING STARTS AT (WHICH IT JUST ASSEMBLED A WHILE BACK). ╘HIS SHOULD
BE THEN, OUR NUMBER OF CHARACTERS WE HAVE.
╫┴╠╦-╘╚╥╧╒╟╚:
╥EGISTER ┘ IS INITIALLY SET TO ZERO IN THE FIRST INSTRUCTION, AS WE WANT TO
BEGIN WITH THE FIRST CHARACTER. ╘HE FIRST CHARACTER IS AT STRING+0, NOT
STRING+1. ╘HIS MAY SEEM A LITTLE BIT ODD AT FIRST, BUT TRY THINKING OF IT THIS
WAY:
╘AKE, FOR EXAMPLE, 3 DISKETTES. ╨UT THEM IN A ROW AND CALL THE ONE ON THE
LEFT "STRING" (OR SOME OTHER NAME). ╘HEN POINT AT "STRING+1", "STRING+2"..
╬OTICE THERE'S NO "STRING+3" EVEN THO' THERE'S 3 DISKETTES? ╘HIS MAY
SEEM A LITTLE BIT STRANGE AT FIRST, BUT AFTER THINKING ABOUT IT A WHILE
YOU'LL BEGIN TO UNDERSTAND. ╔N MACHINE / ASSEMBLY LANGUAGE, YOU TYPICALLY
COUNT STARTING FROM ZERO, IN THE REAL WORLD, TYPICALLY FROM ONE.
╘HE LDA STRING,Y INSTRUCTION IS TELLING THE COMPUTER TO REFERENCE STRING AS
IF IT WAS AN ARRAY, GET THE BYTE AT LOCATION STRING + Y, OR FOR YOU BASIC
PROGRAMMERS THINKING OF STRING AS AN ARRAY OF BYTES (WITH NO BOUNDS CHECKING)
STRING[Y]. ╘HUS, THE ACCUMULATOR IS EQUAL TO THE YTH BYTE STARTING FROM
THE LOCATION STRING IS DEFINED TO BE.
╫E THEN CALL THE ROUTINE ├OMMODORE SO GRACIOUSLY PROVIDED FOR US THAT PRINTS
OUT THE CONTENTS OF THE ACCUMULATOR. ╬OW, SOME ROUTINES, AS WE'LL SEE IN OTHER
EDITIONS, ARE NOT SO NICE AND MAY CHANGE THE VALUE OF THE ACCUMULATOR, THE
X AND Y REGISTERS. ╚OWEVER, ├OMMODORE WAS EXTRA NICE AND THE ROUTINE AT $FFD2 IS
GUARANTEED NOT TO CHANGE ANY OF THE REGISTERS.
╘HE ROUTINE THEN "INY". ╫HAT IS THIS? ╔T "╔╬CREMENTS THE ┘ REGISTER". ╔╬╪
WILL "╔╬CREMENT THE ╪ REGISTER". ╘HE ╪ AND ┘ REGISTER CAN NOT HAVE ANY MATH
PERFORMED ON THEM OTHER THAN INCREMENT AND DECREMENT OPERATIONS (IE: ADDING
ONE AND SUBTRACTING ONE). ╘HE ONLY REGISTER THAT ALLOWS ADDITION OR
SUBTRACTION IS THE ACCUMULATOR. ╚OWEVER, IN THIS CASE WE JUST WANT Y TO POINT
TO THE NEXT CHARACTER, THE NEXT BYTE SO "╔╬┘" SERVES US FINE.
╫E THEN "├OM╨ARE ┘" REGISTER TO THE NUMBER OF CHARACTERS IN THE STRING. ╬OTICE
THE # SIGN. ╔F WE HADN'T HAVE HAD THAT THERE, IT WOULD'VE TRIED TO LOOK AT
WHATEVER MEMORY LOCATION NUMCHARS WAS DEFINED FOR. ╬UMCHARS WAS SET UP TO HOLD
THE NUMBER OF CHARACTERS IN THE STRING, NOT BE A POINTER FOR A MEMORY LOCATION.
╬OW THAT WE'VE COMPARED IT, WE "┬RANCH IF THE LAST COMPARISON WAS ╬OT ┼QUAL"
BACK TO WHERE LOOP IS AT (IN THIS CASE, WHERE WE LOAD A WITH CHARACTER AGAIN).
╔F IT WAS EQUAL WE FALL THROUGH TO THE ╥╘╙ WHERE WE RETURN FROM OUR LITTLE
PROGRAM.
┬ASICALLY, WE'VE GOT SOMETHING LIKE THE FOLLOWING FLOWCHART:
_______
/ ╙╘┴╥╘ \
\_______/
▄
\▄/
+-----------------+
▄ ╙ET ╔NDEX (┘) ▄
▄ FIRST CHARACTER ▄
+-----------------+
▄
\▄/
+-------------------+
▄ ╟ET THE CHARACTER ▄ /
▄ POINTED TO BY ▄<------------------+
▄ THE INDEX(┘) ▄ \ ▄
+-------------------+ ▄
▄ ▄
\▄/ ▄
+-------------+ ▄
▄ ╨RINT IT ▄ ▄
+-------------+ ▄
▄ ▄
\▄/ ▄
+------------------------+ ▄
▄ ╔NCREMENT THE ╔NDEX(┘) ▄ ▄
+------------------------+ ▄
▄ ▄
\▄/ ▄
/\ ▄
/= \ ▄
/# OF\ ▄
/CHARS?\ ▄
/TO PRINT\___NO,NOT =_____------------->+
\??? /
\ /
\ /
\ /
\/
▄
\▄/
_____
/ ┼╬─ \
\_____/
╔NDEXED ADDRESSING IS USED *VERY* OFTEN IN ASSEMBLY LANGUAGE. ╘RY PLAYING
WITH THE SECOND PROGRAM AND EXPERIMENT WITH IT UNTIL YOU UNDERSTAND FULLY WHAT
IS GOING ON. ╬EXT TIME WE'LL LOOK AT HOW TO ACCESS SOME OF THE DISKETTE
ROUTINES AND TO DISPLAY A FILE ON DISK.
===============================================================================
┴N ╔N-─EPTH ╠OOK AT THE 8563 ╓IDEO ├HIP ON THE ├= 128
-----------------------------------------------------
BY ├RAIG ╘AYLOR (DUCK@PEMBVAX1.PEMBROKE.EDU)
─UE TO THE ARTICLE IN THE LAST ISSUE BY ├RAIG ┬RUCE (F2RX@JUPITER.SUN.CSD.UNB.
CA) AND SOME LETTERS FROM PEOPLE ASKING ABOUT HOW THE 8563 ╓IDEO ├HIP WORKS AND
MORE TECHNICAL INFORMATION THIS ARTICLE WILL ATTEMPT TO PRESENT AS MUCH DETAIL
AS POSSIBLE ON THE 8563 CHIP & IT'S VARIOUS CAPIBILITIES.
---------------------
! ╚ARDWARE ┴SPECTS: !
---------------------
╘HE FOLLOWING IS A PHYSICAL LAYOUT OF THE 8563 AND THE AVAILABLE PIN OUTS:
+------------------+
42 O_▄──7 ╓── ├╙ ─┴7▄_O 33 ─┴0-─┴7 - ┴DDRESS ┬US FOR ╥AM
41 O_▄──6 ─┴6▄_O 32 ──0-──7 - ─ATA ┬US FOR ╥AM
40 O_▄──5 ─┴5▄_O 31 ─0 - ─7 - ─ATA ┬US 8563 / ├PU
39 O_▄──4 ─┴4▄_O 30 ├╙ /├╙ - ├HIP ╙ELECTION ╨IN
38 O_▄──3 ─┴3▄_O 29 /╥╙ - ╥EGISTER ╙ELECT
36 O_▄──2 ─┴2▄_O 28 ╥/╫ - ─ATA ─IRECTION FOR ─ATA ┬US
35 O_▄──1 ─┴1▄_O 27 ╔╬╔╘ - ╔NITIALIZE INTERNAL LATCHES
34 O_▄──0 ─┴0▄_O 26 ─╔╙╨┼╬ - (╒NUSED) ─ISPLAY ┼NABLE
▄ ▄ ╥┼╙ - (╒NUSED) ╥ESET ALL SCAN CNTS
▄ ▄ ╘╙╘ - (╒NUSED) ╘EST PURPOSES ONLY
10 O_▄─7 /├┴╙▄_O 48 ─╥/╫ - ╠OCAL ─RAM ╥EAD/╫RITE
11 O_▄─6 /╥┴╙▄_O 47 /╥┴╙ - ╥OW ┴DDRESS ╙TROBE
13 O_▄─5 ─╥/╫▄_O 21 /├┴╙ - ├OLUMN ┴DDRESS ╙TROBE
14 O_▄─4 ▄ ─├╠╦ - ╓IDEO ─OT ├LOCK
15 O_▄─3 ╥▄_O 46 ├├╠╦ - (╒NUSED) ├HARACTER ├LOCK
16 O_▄─2 ╟▄_O 45 ╠╨2 - ╔NPUT FOR ╠IGHT ╨EN
17 O_▄─1 ┬▄_O 44 ╚╙┘╬├ - ╚ORIZONTAL ╙YNC
18 O_▄─0 ╔▄_O 43 ╥,╟,┬,╔ - ╨IXEL ─ATA ╧UTPUTS
▄ ▄
▄ ▄
8 O_▄/╥╙ ▄
7 O_▄/├╙ ▄
9 O_▄╥/╫ ╓╙┘╬▄_O 20
23 O_▄/╥┼╙ ╚╙┘╬▄_O 3
▄ ▄
▄ ├├╠╦▄_O 1
25 O_▄/╠╨2 ─╔╙╨┼╬▄_O 19
▄ ▄
▄ ╘╙╘▄_O 24
2 O_▄/─├╠╦ ╓╙5 ╔╬╔╘▄_O 22
+------------------+
!12
O
╘AKEN FROM ╨G. 596-8 ├=128 ╨ROGRAMMER'S ╥EFERENCE ═ANUAL ╨UBL. ╞EB 1986
┬ANTEM ┬OOKS
+-----------------------------+
▄ ╚OW ├OMMODORE ╚OOKED ╔T ╒P! ▄
+-----------------------------+
╬OW, THE 8563 IS HOOKED UP TO THE COMPUTER VIA THE FOLLOWING METHOD:
+---------------------+
▄ ▄ +--------+ +-------+
▄├OMPUTER ═EMORY ▄ ▄ 8563 ▄ ▄16K OR ▄
▄ (╥┴═) ▄ ▄ ▄ % ▄ 64K ▄
▄ ▄___$D600_____▄DA0-7 ▄ % ▄╓─├ ╥┴═▄
▄ ▄ ▄ ▄ % ▄ ▄
▄ ▄___$D601_____▄DR0-7 ▄ % ▄(╙CREEN▄
▄ ▄ ( /RS) ▄ D0-7▄___▄ ═EM) ▄
+---------------------+ +--------+ +-------+
├ONFUSING 'EH? (╘HE %'S REPRESENT CONTROL SIGNALS THAT ALSO ARE USED).. ╫HAT
BASICALLY HAPPENS IS THAT EVERY TIME THE COMPUTER WANTS TO ACCESS THE 8563 TO
PROGRAM OR CHANGE ONE OF IT'S NUMEROUS REGISTERS IT HAS TO STORE THE REGISTER
NUMBER TO $D600, THEN LOOP UNTIL THE 7TH BIT OF $D600 CHANGES TO A 1. ╧NCE
THIS IS DONE, YOU CAN THEN READ OR WRITE A VALUE TO/FROM $D601.
├OMMODORE ALSO EMPLOYED THE ══╒ (═EMORY ═ANAGEMENT ╒NIT) TO MANIPULATE PAGES
OF MEMORY AND THUS, THE 8563 ONLY SHOWS UP IN THE ╔/╧ PAGE (USUALLY REFERENCED
AS ┬ANK 15 OR A VALUE OF $00 IN THE ══╒ ╥EGISTER AT $FF00) OR IN PAGES THAT THE
╔/╧ SECTION OF MEMORY IS ENABLED.
╘HE REGISTER AT $D600 IN THE ╔/╧ SPACE OF THE ├=128 IS LAID OUT AS FOLLOWS:
┬IT ╨OSITION:
7 6 5 4 3 2 1 0
╙TATUS ╠IGHT╨EN ╓┬LANK -----╒NUSED---- ------╓ERSION #--------
╫HEN A VALUE IS PLACED IN $D600 INSTEAD OF PUTTING THE VALUE IN ╙TATUS,
╠IGHT╨EN BITS ETC, THE VALUE REFLECTS WHICH REGISTER # IS REQUESTED. ┬IT 7 OF
THIS REGISTER (╙TATUS) WILL THEN RETURN A BINARY 1 WHEN $D601 REFLECTS THE
ACTUAL VALUE OF THE REGISTER JUST POKED TO $D600. (╙EE THE ═╠ ROUTINES FOR
STORING AND READING VALUES TO/FROM REGISTERS AT THE END OF THIS ARTICLE). ╫HEN
A VALUE IS FIRST PLACE IN THIS REGISTER, $D600 BIT 7 IS EQUAL TO A ZERO.
┬IT 6, IS USED TO INDICATE WHEN NEW VALUES HAVE BEEN LATCHED INTO THE
LIGHTPEN REGISTERS (16-17). ┬IT 5, ╓┬LANK REFERS TO WHEN THE 8563 IS IN THE
PERIOD KNOWN AS "╓ERTICAL ┬LANKING ╨ERIOD". ╒SUALLY, HOWEVER THIS BIT IS
SELDOM REFERRED TO AS UPDATING THE 8563 IS USALLY TOO SLOW TO MAKE USE OF THIS
FOR ANY SPECIAL EFFECTS.
┬ITS 0-2 RETURN A VERSION # OF WHICH %000 AND %001 ARE THE KNOWN VERSIONS OUT.
┼ARLY 128'S WILL CONTAIN THE VALUE OF $0 WHILE LATER 128'S WILL CONTAIN THE
VALUE OF $1. ╬OTE THAT THERE ARE SLIGHT DIFFERENCES BETWEEN THE 8563'S, IN THAT
REGISTER 25 (HORIZONTAL SMOOTH SCOLL REGISTER) REQUIRES DIFFERENT SETTINGS.
╘HE REGISTER AT $D601 RETURNS THE VALUE OF REGISTER # THAT HAS BEEN WRITTEN
INTO $D601 (WHEN BIT 7 OF $D600 = %1). ╬OTE THAT STORING A VALUE HERE WILL ALSO
DO A WRITE INTO THE REGISTER # SELECTED. (╥EFER TO THE ═╠ ROUTINES FOR STORING
AND READING VALUES TO/FROM REGISTERS AT THE END OF THIS ARTICLE FOR AN EXAMPLE).
------------------------
▄ ╥EGISTER ─EFINITIONS ▄
------------------------
╥EG# 7 6 5 4 3 2 1 0 ─ESCRIPTION ╬OTES
------- ---- ---- ---- ---- ---- ---- ---- ---- ------------------------ -----
0 ╚Z╘7 ╚Z╘6 ╚Z╘5 ╚Z╘4 ╚Z╘3 ╚Z╘2 ╚Z╘1 ╚Z╘0 ╚ORIZONTAL ╘OTAL ^1
1 ╚Z─7 ╚Z─6 ╚Z─5 ╚Z─4 ╚Z─3 ╚Z─2 ╚Z─1 ╚Z─0 ╚ORIZONTAL ─ISPLAYED ^1
2 ╚Z╙7 ╚Z╙6 ╚Z╙5 ╚Z╙4 ╚Z╙3 ╚Z╙2 ╚Z╙2 ╚Z╙0 ╚ORIZONTAL ╙YNC ╨OSITION ^1
3 ╓╙╫3 ╓╙╫2 ╓╙╫1 ╓╙╫0 ╚╙╫3 ╚╙╫2 ╚╙╫1 ╚╙╫0 ╓ERT/╚ORIZ. ╙YNC ╫IDTH ^2
4 ╓E╘7 ╓E╘6 ╓E╘5 ╓E╘4 ╓E╘3 ╓E╘2 ╓E╘1 ╓E╘0 ╓ERTICAL ╘OTAL ^3
5 .... .... .... ╓E┴4 ╓E┴3 ╓E┴2 ╓E┴1 ╓E┴0 ╓ERTICAL ╘OTAL ╞INE ┴DJU ^3
6 ╓E─7 ╓E─6 ╓E─5 ╓E─4 ╓E─3 ╓E─2 ╓E─1 ╓E─0 ╓ERTICAL ─ISPLAYED ^3
7 ╓E╙7 ╓E╙6 ╓E╙5 ╓E╙4 ╓E╙3 ╓E╙2 ╓E╙1 ╓E╙0 ╓ERTICAL ╙YNC ╨OSITION ^2
8 .... .... .... .... .... .... ╔LC1 ╔LC0 ╔NTERLACE ═ODE ^4
9 .... .... .... ├╘╓4 ├╘╓3 ├╘╓2 ├╘╓1 ├╘╓0 ├HARACTER ╘OTAL ╓ERTICAL ^5
10 .... ├R═1 ├R═0 ├SS4 ├SS3 ├SS2 ├SS1 ├SS0 ├URSOR ═ODE/ ╙TART ╙CAN ^6
11 .... .... .... ├ES4 ├ES3 ├ES2 ├ES1 ├ES0 ├URSOR ┼ND ╙CAN ^6
12 ─S15 ─S14 ─S13 ─S12 ─S11 ─S10 ─S09 ─S08 ─ISPLAY ╙TART ┴DRS (╚I) ^7
13 ─S07 ─S06 ─S05 ─S04 ─S03 ─S02 ─S01 ─S00 ─ISPLAY ╙TART ┴DRS (╠O) ^7
14 ├P15 ├P14 ├P13 ├P12 ├P11 ├P10 ├P09 ├P08 ├URSOR ╨OSITION (╚I) ^7
15 ├P07 ├P06 ├P05 ├P04 ├P03 ├P02 ├P01 ├P00 ├URSOR ╨OSITION (╠O) ^7
16 ╠P╓7 ╠P╓6 ╠P╓5 ╠P╓4 ╠P╓3 ╠P╓2 ╠P╓1 ╠P╓0 ╠IGHT ╨EN ╓ERITCAL ^8
17 ╠P╚7 ╠P╚6 ╠P╚5 ╠P╚4 ╠P╚3 ╠P╚2 ╠P╚1 ╠P╚0 ╠IGHT ╨EN ╚ORIZONTAL ^8
18 ╒A15 ╒A14 ╒A13 ╒A12 ╒A11 ╒A10 ╒A09 ╒A08 ╒PDATE ┴DDRESS (╚I) ^9
19 ╒A07 ╒A06 ╒A05 ╒A04 ╒A03 ╒A02 ╒A01 ╒A00 ╒PDATE ┴DDRESS (╠O) ^9
20 ┴T15 ┴T14 ┴T13 ┴T12 ┴T11 ┴T10 ┴T09 ┴T08 ┴TTRIBUTE ╙TART ┴DRS (╚I) ^7
21 ┴T07 ┴T06 ┴T05 ┴T04 ┴T03 ┴T02 ┴T01 ┴T00 ┴TTRIBUTE ╙TART ┴DRS (╠O) ^7
22 ╚C╨3 ╚C╨2 ╚C╨1 ╚C╨0 ╔C╙3 ╔C╙2 ╔C╙1 ╔C╙0 ╚Z ├HR ╨XL ╘TL/╔├HAR ╙PC ^┴
23 .... .... .... ╓C╨4 ╓C╨3 ╓C╨2 ╓C╨1 ╓C╨0 ╓ERT. ├HARACTER ╨XL ╙PC ^5
24 ┬LK═ ╥VS╙ ╓SS5 ╓SS4 ╓SS3 ╓SS2 ╓SS1 ╓SS0 ┬LOCK/╥VS ╙CR/╓. ╙CROLL ^9^┬^├
25 ╘EXT ┴TRI ╙EMI ─BLE ╚SS3 ╚SS2 ╚SS1 ╚SS0 ─IFF. ═ODE ╙W/╚. ╙CROLL ^─,^┼
26 ╞GD3 ╞GD2 ╞GD1 ╞GD0 ┬GD3 ┬GD2 ┬GD1 ┬GD0 ╞ORE╟ROUND/┬ACK╟ROUND ├OL ^╞
27 ╥IN7 ╥IN6 ╥IN5 ╥IN4 ╥IN3 ╥IN2 ╥IN1 ╥IN0 ╥OW/┴DRS. ╔NCREMENT ^╟
28 ├╙A2 ├╙A1 ├╙A0 ╥AM╘ .... .... .... .... ├HARACTER ╙ET ┴DDRS/╥AM ^╚,^╔
29 .... .... .... ╒D╠4 ╒D╠3 ╒D╠2 ╒D╠1 ╒D╠0 ╒NDERLINE ╙CAN ╠INE ^6
30 ╫D├7 ╫D├6 ╫D├5 ╫D├4 ╫D├3 ╫D├2 ╫D├1 ╫D├0 ╫ORD ├OUNT (-1) ^9
31 ─TA7 ─TA6 ─TA5 ─TA4 ─TA3 ─TA2 ─TA1 ─TA0 ─ATA ^9
32 ┬LK╞ ┬LK┼ ┬LK─ ┬LK├ ┬LK┬ ┬LK┴ ┬LK9 ┬LK8 ┬LOCK ├OPY ╙OURCE (HI) ^9
33 ┬LK7 ┬LK6 ┬LK5 ┬LK4 ┬LK3 ┬LK2 ┬LK1 ┬LK0 ┬LOCK ├OPY ╙OURCE (LO) ^9
34 ─E┬7 ─E┬6 ─E┬5 ─E┬4 ─E┬3 ─E┬2 ─E┬1 ─E┬0 ─ISPLAY ┼NABLE ┬EGIN ^╩
35 ─E┼7 ─E┼6 ─E┼5 ─E┼4 ─E┼3 ─E┼2 ─E┼1 ─E┼0 ─ISPLAY ┼NABLE ┼ND ^╩
36 .... .... .... .... ─RM3 ─RM2 ─RM1 ─RM0 ─╥┴═ ╥EFRESH ╥ATE ^╦
+-----------------+
▄ ╥EGISTER ╒SAGE: ▄
+-----------------+
^1 : ╥EGISTER #0: ╚ORIZONTAL ╘OTAL
--- ╥EGISTER #1: ╚ORIZONTAL ─ISPLAYED
╥EGISTER #2: ╚ORIZONTAL ╙YNC ╨ULSE
╘HESE TWO REGISTER FUNCTION TO DEFINE THE DISPLAY WIDTH OF THE SCREEN.
╥EGISTER 0 WILL CONTAIN THE NUMBER OF CHARACTERS MINUS 1 BETWEEN SUCESSIVE
HORIZONTAL SYNC PULSES, THE HORIZONTAL BORDER AND THE INTERVAL BETWEEN
HORIZONTAL SYNC PULSES. ╘HE NORMAL VALUE FOR THIS IS USUALLY SET TO 126.
╥EGISTER 1 SPECIFIES HOW MANY OF THE POSITIONS AS SPECIFIED IN REGISTER 0 CAN
ACTUALLY BE USED TO DISPLAY CHARACTERS. ╘HE DEFAULT VALUE FOR THIS IS 80.
╘HE ╓─├ CAN TAKE VALUES LESS THAN 80 AND THUS, WILL ONLY DISPLAY THAT MANY
CHARACTERS. ┴ USEFUL EFFECT CAN BE A SWEEP FROM THE RIGHT BY INCREMENTING
THE VALUE HERE FROM 1 TO 80. ╥EGISTER #2 SPECIFIES THE STARTING CHARACTER
POSITION AT WHICH THE VERTICAL SYNC PULSE BEGINS. ╘HUS, IT ALSO DETERMINES
WHERE ON THE ACTIVE SCREEN CHARACTERS APPEAR. ┴ DEFAULT VALUE OF 102,
INCREASING THE VALUE MOVES THE SCREEN TO THE LEFT, DECREASING IT MOVES IT TO
THE RIGHT.
^2 : ╥EGISTER #3: ╓ERTICAL / ╚ORIZONTAL ╙YNC ╨OSITION.
---- ╥EGISTER #7: ╓ERTICAL ╙YNC ╨OSITION
╔N ╥EGISTER 3, ┬ITS 0-3 OF THIS REGISTER SPECIFIES THE HORIZONTAL SYNC WIDTH
AND SHOULD BE EQUAL TO 1 + THE NUMBER OF PIXELS PER CHARACTER. ╘HUS, THE VALUE
HERE IS NORMALLY 1+8 OR 9. ┬ITS 4-7 OF REGISTER 3 SPECIFY THE VERTICAL SYNC
WIDTH AND NORMALLY CONTAINS A VALUE OF 4. ╞OR INTERLACE SYNC AND VIDEO MODE,
USE A VALUE THAT IS TWICE THE NUMBER OF SCAN LINES DESIRED. ╥EGISTER #7 ALLOWS
FOR ADJUSTMENT OF WHERE THE VERTICAL SYNC WILL BE GENERATED ALLOWING SHIFTING
OF THE ACTUAL DISPLAY UP AND DOWN. ╬ORMALLY, A VALUE OF 4, DECREASING THE VALUE
WILL MOVE THE SCREEN DOWN, INCREASING IT WILL APPEAR TO MOVE IT UPWARDS.
^3 : ╥EGISTER #4: ╓ERTICAL ╘OTAL
---- ╥EGISTER #5: ╓ERTICAL ╘OTAL ╞INE ┴DJUST
╥EGISTER #6: ╓ERTICAL ─ISPLAYED
╥EGISTER #4 OF THIS REGISTER DETERMINES THE TOTAL NUMBER OF SCREEN ROWS,
INCLUDING THE ROWS FOR THE ACTIVE DISPLAY, AND THE TOP AND BOTTOM BORDERS IN
ADDITION TO THAT OF THE VERTICAL SYNC WIDTH. ╘HE VALUE HELD HERE IS NORMALLY
A VALUE OF 32 FOR ╬╘╙├ SYSTEMS (╒╙ ╙TANDARD) OR 39 FOR ╨┴╠(┼UROPEAN) SYSTEMS.
╥EGISTER #5 HOLDS IN BITS 0-4 A "FINE-ADJUST" WHERE ANY EXTRA SCAN LINES THAT
ARE NECESSARY TO MAKE UP THE DISPLAY CAN BE SPECIFIED HERE. ╘HE VALUE HERE IS
NORMALLY A 0 IN BOTH THE ╬╘╙├ AND ╨┴╠ INITIALIZATIONS BY THE KERNAL AND BITS
5-7 ARE UNUSED, ALWAYS RETURNING A BINARY 1111. ╥EGISTER #6 SPECIFIES THE TOTAL
NUMBER OF THE VERTICAL CHARACTER POSITIONS (AS SET IN ╥EGISTER 4) THAT CAN BE
USED FOR ACTUAL DISPLAY OF CHARACTERS. ╘HUS, THIS REGISTER USUALLY HOLDS A
VALUE OF 25 FOR A STANDARD 25-ROW DISPLAY.
^4 : ╥EGISTER #8: ╔NTERLACE ═ODE ├ONTROL
----
╥EGISTER 8 ALLOWS CONTROL OF VARIOUS DISPLAY MODES THE 8563 CAN GENERATE.
┬ITS 0 AND 1 ARE THE ONLY BITS USED IN THIS REGISTER, THE REST ALWAYS READING
A BINARY 1. ┬ITS 0 AND 1 ARE CONFIGURED AS FOLLOWS:
┬INARY %00, %10 - ╬ON╔NTERLACED ═ODE
%01 - ╔NTERLACED ╙YNC
%11 - ╔NTERLACED ╙YNC AND ╓IDEO
╬OTE THAT THE DEFAULT VALUE IS $00 WHICH IS STANDARD, NON-INTERLACED.
╔NTERLACED SYNC DRAWS EACH HORIZONTAL SCAN LINE TWICE BUT APPEARS TO SUFFER FROM
AN ANNOYING JITTER DUE TO HOW IT IS DRAWN. ╔NTERLACED ╙YNC AND ╓IDEO DRAWS TWICE
AS MANY LINES, THUS DOUBLING THE RESOLUTION. ╚OWEVER, IT ALSO SUFFERS FROM
JITTER AND THAT IS WHY MOST MONITORS SUFFER HORRIBLY WHEN USING PROGRAMS THAT
SUPPORT 30 COLUMNS OR GREATER. ╬OTE THAT FOR INTERLACED SYNC AND VIDEO, THE
FOLLOWING REGISTERS WILL NEED TO BE CHANGED: #'S: 0,4,6,7,8.
^5 : ╥EGISTER #9: ╘OTAL ╙CAN ╠INES ╨ER ├HARACTER
----
┬ITS 0-4 OF THIS REGISTER ARE THE ONLY RELEVANT ONES, THE REST RETURNING A
BINARY 1. ┬ITS 0-4 DETERMINE THE CHARACTER HEIGHT IN SCAN-LINES OF DISPLAYED
CHARACTERS AND ALLOW UP TO SCAN-LINE HEIGHTS OF 32 SCAN LINES. ╘HE ╓─├ NORMALLY
SETS ASIDE 16 BYTES FOR EACH CHARACTER (NORMALLY, EACH BYTE IS EQUIVLENT TO
1 SCAN LINE) SO THE VALUE HERE COULD BE INCREASED TO 16-1 AND A DOUBLE-HEIGHT
CHARACTER SET COULD BE LOADED IN. ╬OTE, HOWEVER THAT VALUES LESS THAN 16 WILL
TELL THE ╓─├ TO USE A 8,192 BYTE CHARACTER SET (NORMAL) WHILE SPECIFYING VALUES
GREATER THAN 16 WILL MAKE IT USE 32 BYTES PER CHARACTER EVEN IF SOME OF THE
BYTES ARE NOT USED.
^6 : ╥EGISTER #10: ├URSOR ═ODE / ╙TART ╙CAN ╠INE
---- ╥EGISTER #11: ├URSOR ┼ND ╙CAN ╠INE.
╥EGISTER #29: ╒NDER╠INE ╙CAN ╠INE ├ONTROL.
╘HESE REGISTERS ALLOW THE USER TO SPECIFY THE CURSOR BLINK MODE, AS WELL AS
THE STARTING AND ENDING SCAN LINES FOR THE CURSOR (ALLOWING A FULL SOLID,
AN UNDERLINE, ┬ITS 0-4 OF REGISETER #10 DETERMINES THE SCAN LINE WITHIN EACH
POSITION FOR THE TOP OF THE CURSOR. ╬ORMALLY, THIS VALUE HOLDS A VALUE
OF 0 FOR THE BLOCK CURSOR, OR A VALUE OF 7 FOR THE UNDERLINE CURSOR. ┬ITS 5-6 OF
╥EGISTER 10 SPECIFY THE BLINK RATE FOR THE CURSOR. ┴ VALUE OF %00 SPECIFIES NO
BLINK, IE: A SOLID CURSOR. ┴ VALUE OF %01 SPECIFIES NO CURSOR, A VALUE OF %10
SPECIFIES A FLASH RATE OF 1/16 THE SCREEN REFRESH RATE, WHILE A VALUE OF %11
SPECIFIES A FLASH RATE OF 1/32 THE SCREEN REFRESH RATE. ╬OTE THAT BIT 7 OF
╥EGISTER 10 IS UNUSED AND NORMALLY RETURNS A BINARY 1. ╥EGISTER 11 SPECIFIES
THE BOTTOM SCAN LINES IN BITS 0-4, THE OTHER UNUSED BITS RETURNING A BINARY 1.
╘HE VALUE HELD IN THESE BITS USUALLY IS 7 FOR THE BLOCK AND UNDERLINE CURSOR
MODES IN THE NORMAL 128 EDITOR. ╥EGISTER #29 IS USED TO INDICATE WHERE THE SCAN
LINE IS "SET" IN THE CHARACTER. ╘HE "UNDERLINE" IS ONLY 1 PIXEL TALL AND THUS,
THIS LOCATION JUST INDICATES THE START AND END LOCATION IN PIXELS, SIMILAIR TO
REGISTERS #10 AND #11 BEING THE SAME VALUE. ╬OTE THAT BITS 5-7 OF THIS REGISTER
IS UNUSED AND NORMALLY RETURN A BINARY 1.
^7 : ╥EGISTER #12: ─ISPLAY ╙TART ┴DDRESS (╚I)
---- ╥EGISTER #13: ─ISPLAY ╙TART ┴DDRESS (╠O)
╥EGISTER #14: ├URSOR ╨OSITION (╚I)
╥EGISTER #15: ├URSOR ╨OSITION (╠O)
╥EGISTER #20: ┴TTRIBUTE ╙TART ┴DDRS (╚I)
╥EGISTER #21: ┴TTRIBUTE ╙TART ┴DDRS (╠O)
╬OTE FIRST, THAT ALL OF THESE REGISTERS ARE GROUPED IN ╚I BYTE, ╠O BYTE ORDER
WHICH IS USUALLY DIFFERENT FROM THE 6502 CONVENTION OF LOW BYTE, HI BYTE (IE:
IN NORMAL 6502 ML, $C000 IS STORED AS $00 $C0, HOWEVER IN THE 8563 IT WOULD BE
STORED AS $C0 $00). ╥EGISTERS 12 AND 13 DETERMINE, WHERE IN ╓─├ MEMORY THE
8563 IS THE START OF THE SCREEN. ╔NCREMENTING THIS VALUE BY 80 (THE NUMBER OF
CHARACTERS PER LINE) AND WITH A LITTLE ADDITIONAL WORK CAN PROVIDE A VERY
EFFECIENT WAY OF HAVING A SCREEN THAT "SEEMS" TO BE LARGER THAN JUST 80X25.
╘HE CURSOR POSITION IN REGISTERS 14 AND 15 REFLECT THE ACTUAL CHARACTER IN
MEMORY THAT THE CURSOR CURRENTLY LIES OVER. ╔F IT'S NOT ON THE DISPLAY SCREEN,
THEN IT IS NOT DISPLAYED. ╥EGISTERS 20 AND 21 REFLECT WHERE IN THE 8563 MEMORY
ATTRIBUTE MEMORY IS HELD. ┴TTRIBUTE MEMORY REFERS TO THE CHARACTER ATTRIBUTES
SUCH AS FLASH, INVERSE VIDEO, COLOR ETC THAT CAN BE SET FOR EACH CHARACTER.
^8 : ╥EGISTER #16: ╠IGHT ╨EN ╓ERTICAL
---- ╥EGISTER #17: ╠IGHT ╨EN ╚ORIZONTAL
╘HESE REGISTERS RETURN THE LIGHT PEN POSITION AND REFER TO THE ACTUAL
CHARACTER POSITIONS ON SCREEN (IE: VALUES RANGING FROM 1..25 FOR VERTICAL).
╘HE HORIZONTAL READING WILL NOT CORROSPOND EXACTLY TO CHARACTER POSITIONS, BUT
WILL RANGE FROM VALUES OF 27-29 TO 120 DEPENDING ON THE EDGE OF THE SCREEN.
╔T'S RECOMMENDED THAT THE HORIZONTAL CHARACTER POSITION IS GIVEN MORE TOLERANCE
THAN THE VERTICAL LIGHT PEN POSITION FOR THIS REASON.
^9 : ╥EGISTER #18: ╒PDATE ┴DDRESS (╚I)
---- ╥EGISTER #19: ╒PDATE ┴DDRESS (╠O)
╥EGISTER #24:7 ├OPY / ╞ILL ┬IT
╥EGISTER #30: ╫ORD ├OUNT(-1)
╥EGISTER #31: ─ATA
╥EGISTER #32: ┬LOCK ├OPY ╙RC (╚I)
╥EGISTER #33: ┬LOCK ├OPY ╙RC (╠O)
╘HESE REGISTERS ALLOW CONTROL AND MANIPULATION OF THE 16K OR 64K BLOCK WITHIN
THE 8563 MEMORY. ╥EGISTERS 18 AND 19 POINT TO WHERE IN ╓─├ MEMORY THE NEXT
READ OR WRITE WILL TAKE PLACE FROM. ╥EGISTER 30 SPECIFIES THE NUMBER OF BYTES
- 1 TO COPY OR FILL DEPENDING ON BIT # 7 OF REGISTER #24. ╬ORMALLY, THE 8563
WILL AUTOMATICALLY PERFORM THE DESIGNATED OPERATION (OF WHAT BIT 7 OF REGISTER
#24 SAYS) WHEN REGISTER #31 (THE DATA BYTE) IS WRITTEN TO. ╥EGISTERS 18 AND 19
AUTOMATICALLY UPDATE UPON READ OR WRITE, SO THAT IS WHY REGISTER #30 SPECIFIES
A VALUE 1 LESS THAN WHAT IS ACTUALLY NEEDED. ╥EGISTER #31, AS ALREADY MENTIONED
IS THE BYTE TO WRITE FOR REGISTER #30 TIMES (OR COPY FROM ╥EGISTER#32 / #33).
╔F REGISTER #24, BIT 7 IS SPECIFIED AS A BINARY 1 THEN THE MEMORY IS COPIED FROM
THE ADDRESS IN ╓─├ MEMORY POINTED TO BY REGISTERS #32 AND #33.
^┴ : ╥EGISTER #22: ├HARACTER ╚ORIZONTAL ╙IZE ├ONTROL
----
┬ITS 0-3 OF THIS REGISTER DETERMINES HOW MANY HORIZONTAL PIXELS ARE USED
FOR EACH DISPLAYED CHARACTER. ╓ALUES GREATER THAN 8 HERE RESULT IN APPARENT
GAPS IN THE DISPLAY. ╔NTER-CHARACTER SPACING CAN BE ACHIEVED BY SETTING THIS
VALUE GREATER THAN THAT OF BITS 4-7. ┬ITS 4-7 DETERMINE THE WIDTH OF EACH
CHARACTER POSITION IN PIXELS. ╘HUS, WHILE BITS 0-3 ALLOCATE N-PIXELS, BITS
4-7 SPECIFY HOW MANY OF THOSE PIXELS ARE USED FOR CHARACTER DISPLAY.
^┬ : ╥EGISTER #24:5 ╥EVERSE ╙CREEN ┬IT
---- ╥EGISTER #24:6 ┬LINK ╥ATE FOR ├HARACTERS.
┬IT #6 SPECIFIES FOR THE ╓─├ FOR ALL PIXELS NORMALLY UNSET ON THE ╓─├ SCREEN
TO BE SET, AND ALL SET PIXELS TO BE UNSET. ┬IT #5 SPECIFIES THE BLINK RATE
FOR ALL CHARACTERS WITH THE BLINK ATTRIBUTE. ╙ETTING THIS TO A BINARY 1
SPECIFIES A BLINK RATE OF 1/32 THE REFRESH RATE, WHILE A BINARY 0 IS EQUIVLANT
TO A BLINK RATE 1/16TH OF THE REFRESH RATE.
^├ : ╥EGISTER #24:0-4 ╓ERTICAL ╙MOOTH ╙CROLL
----
╘HE 8563 PROVIDES FOR A SMOOTH SCROLL, ALLOWING BITS 0-4 TO FUNCTION AS AN
INDICATOR OF THE NUMBER OF BITS TO SCROLL THE SCREEN VERTICALLY UPWARD.
^─ : ╥EGISTER #25:7 ╘EXT OR ╟RAPHICS ═ODE ╔NDICATOR ┬IT
---- ╥EGISTER #25:6 ═ONOCHROME ═ODE ┬IT
╥EGISTER #25:5 ╙EMI-╟RAPHICS ═ODE
╥EGISTER #25:4 ─OUBLE-╨IXEL ═ODE
╘HE 8563 ALLOWS THE IMPLEMENTATION OF A GRAPHICS MODE, IN WHERE ALL OF THE 16K
OF THE SCREEN MAY BE BIT-MAPPED SEQUENTIALLY RESULTING IN A RESOLUTION OF
640X200 (SEE ├RAIG ┬RUCE'S 8563 ╠INE-╨LOTTING ROUTINE IN THE FIRST ISSUE FOR A
MORE DETAILED EXPLANATION OF THIS FEATURE). ╙ETTING THIS BIT TO 1 SPECIFIES
GRAPHICS MODE, BINARY 0 INDICATES TEXT MODE. ┬IT 6 INDICATES TO THE 8563 WHERE
TO OBTAIN ITS COLOR INFORMATION ETC, ABOUT THE CHARACTERS. ┬IT 6 WHEN IT IS A
BINARY 0 RESULTS IN THE 8563 TAKING IT'S COLOR INFORMATION FROM BITS 4-7 OF
REGISTER 26. ╫HEN THIS BIT IS A BINARY 1, THE ATTRIBUTE MEMORY IS USED TO
OBTAIN COLOR, FLASH, REVERSE INFORMATION. ┴LSO NOTE THAN WHEN THIS BIT IS A
BINARY 1 THAT ONLY THE FIRST OF THE TWO CHARACTER SETS IS AVAILABLE. ┬IT #5
INDICATES A SEMI-GRAPHICS MODE THAT ALLOWS THE RIGHTMOST PIXEL OF ANY CHARACTERS
TO BE REPEATED THROUGH-OUT THE INTERCHARACTER SPACING GAP. ┴CTIVATING IT ON THE
NORMAL DISPLAY WILL RESULT IN WHAT APPEARS TO BE A "DIGITAL" CHARACTER FONT. ╘HE
8563 WITH BIT #4 ALLOWS A PIXEL-DOUBLE FEATURE WHICH RESULTS IN ALL DISPLAYED
HORIZONTAL PIXELS HAVING TWICE THEIR USUAL SIZE. ╘HUS, A 40 COLUMN SCREEN IS
EASILY OBTAINABLE ALTHOUGH THE VALUES IN REGISTERS #00-#02 MUST BE HALVED.
^┼ : ╥EGISTER #25: ╚ORIZONTAL ╙MOOTH ├ONTROL
----
╘HIS REGISTER IS ANALOGOUS TO REGISTER #24 ╓ERTICAL ╙MOOTH ├ONTROL AND
FUNCTIONS SIMILAIRLY. ╔NCREASING THIS BITS MOVES THE SCREEN ONE PIXEL TO THE
RIGHT, WHILE DECREASING THEM MOVES THE SCREEN ONE PIXEL TO THE LEFT.
^╞ : ╥EGISTER #26: ╞ORE╟ROUND / ┬ACK╟ROUND ├OLOR ╥EGISTER
----
╘HIS REGISTER, IN BITS 0-3 SPECIFIES THE BACKGROUND COLOR OF THE DISPLAY WHILE
BITS 4-7 SPECIFY THE FOREGROUND CHARACTER COLORS WHEN ATTRIBUTES ARE DISABLED
(VIA BIT 6 OF REGISTER #25). ╬OTE, THESE ARE NOT THE USUAL ├= COLORS BUT ARE
INSTEAD ORGANIZED AS FOLLOWS:
┬IT ╓ALUE ─ECIMAL ╓ALUE ├OLOR
---------------------------------- +-----------------------------+
%0000 0 / $00 ┬LACK ▄ ╬OTE: ┬IT 0 = ╔NTENSITY ▄
%0001 1 / $01 ─ARK ╟RAY ▄ ┬IT 1 = ┬LUE ▄
%0010 2 / $02 ─ARK ┬LUE ▄ ╥╟┬╔ ┬IT 2 = ╟REEN ▄
%0011 3 / $03 ╠IGHT ┬LUE ▄ ┬IT 3 = ╥ED ▄
%0100 4 / $04 ─ARK ╟REEN ▄ ▄
%0101 5 / $05 ╠IGHT ╟REEN +-----------------------------+
%0110 6 / $06 ─ARK ├YAN
%0111 7 / $07 ╠IGHT ├YAN
%1000 8 / $08 ─ARK ╥ED
%1001 9 / $09 ╠IGHT ╥ED
%1010 10 / $0┴ ─ARK ╨URPLE
%1011 11 / $0┬ ╠IGHT ╨URPLE
%1100 12 / $0├ ─ARK ┘ELLO
%1101 13 / $0─ ╠IGHT ┘ELLOW
%1110 14 / $0┼ ╠IGHT ╟RAY (─ARK ╫HITE)
%1111 15 / $0╞ ╫HITE
^╟ : ╥EGISTER #27: ╥OW ┴DDRESS ─ISPLAY ╔NCREMENT
----
╘HIS REGISTER SPECIFIES THE NUMBER OF BYTES TO SKIP, WHEN DISPLAYING
CHARACTERS ON THE 8563 SCREEN. ╬ORMALLY, THIS BYTE HOLDS A VALUE OF $00
INDICATING NO BYTES TO SKIP; HOWEVER TYPICALLY PROGRAMS THAT "SCROLL" THE
SCREEN DO SO BY SETTING THIS TO 80 OR 160 ALLOWING THE PROGRAM TO THEN ALTER
THE ╙CREEN ╙TART (╥EGISTERS #12 AND #13) AND APPEAR TO "SCROLL". ╬OTE THE
NORMAL ├= 128 ╦ERNAL ╙CREEN ┼DITOR DOES NOT SUPPORT THIS FUNCTION.
^╚ : ╥EGISTER #28:7-5 ├HARACTER ╙ET ┴DDRESS
----
╘HESE BITS INDICATE THE ADDRESS OF SCREEN MEMORY * 8K. ╘HUS THE VALUES IN
THESE BITS MAY BE MULTIPLIED BY 8192 TO OBTAIN THE STARTING CHARACTER SET
POSITION (NORMALL THESE BITS HOLD A VALUE OF $01 INDICATING THE CHARACTER
SET BEGINS AT 8192). ╬OTE THAT THE CHARACTER SET IS NOT IN ╥╧═, BUT IS USUALLY
COPIED TO 8192 WHEN THE COMPUTER IS FIRST TURNED ON AND THE 8563 IS INITIALIZED.
(┼XAMINE THE ╔╬╔╘80 ROUTINE AT $├┼0├ IN BANK 15).
^╔ : ╥EGISTER #28:4 ╥AM ├HIP ╘YPE
----
╘HIS BIT SPECIFIES WHETHER 16K OR 64K OF ╥┴═ HAS BEEN INSTALLED. ╬OTE, HOWEVER
THAT THIS VALUE MAY NOT REFLECT FUTURE UPGRADES FROM 16K TO 64K. ╔T IS BEST,
IF A PROGRAM IS DEPENDANT ON 64K TO WRITE TO AN ADDRESS > 16K AND SEE IF IT
IS MIRRORED AT ANY OTHER LOCATION IN ANOTHER SECTION OF MEMORY. ╘HIS BIT HAS A
BINARY VALUE OF 0 IF 16K OR 1 IF 64K ╥┴═.
^╩ : ╥EGISTER #34: ─ISPLAY ┼NABLE ┬EGIN
---- ╥EGISTER #35: ─ISPLAY ┼NABLE ┼ND
╘HE 8563 CAN EXTEND IT'S HORIZONTAL BLANKING INTERVAL TO BLANK A PORTION OF
THE DISPLAYED SCREEN. ╘HE VALUE IN REGISTER #34 DETERMINES THE RIGHTMOST
BLANKED COLUMN, AND REGISTER #35 DETERMINES THE LEFTMOST BLANKED COLUMN. ╬OTE
THAT A VALUE OF 6 USUALLY CORRESPONDS TO THE LEFTMOST COLUMN OF THE SCREEN,
WHILE A VALUE OF 85 CORRESPONDS TO THE RIGHTMOST COLUMN. ╘HIS FEATURE IS USEFUL
FOR "INSIDE-OUT" WRAPS IN WHICH BOTH THE RIGHT AND LEFT MARGIN CAN CLOSE-IN ON
TEXT, THE TEXT CAN BE CLEARED, THESE VALUES RESET ETC...
^╦ : ╥EGISTER #36: ╥EFRESH ├YCLES PER ╙CAN ╠INE
----
╘HIS REGISTER IN BITS 0-3 ALLOWS THE USER (IF HE HAD ANY REASON) TO SPECIFY
THE NUMBER OF REFRESH CYCLES FOR MEMORY FOR THE RAM. ╙ETTING THIS VALUE TOO
LOW MAY CAUSE THE ╥┴═ TO NOT REMEMBER ALL THE INFORMATION. ├HANGING THIS VALUE
GIVES SOME ADVANTAGE, IN TERMS OF DISPLAY SPEED INCREASES BUT IS NOT ADVISED.
╘HE VALUE NORMALLY HELD HERE IS $05, FOR FIVE REFRESH CYCLES PER SCAN LINE.
+--------------------------+
▄ 8563 ═EMORY ╧RGANIZATION ▄
+--------------------------+
╬ORMALLY, THE EXTRA MEMORY OF THE ├=128'S EQUIPPED WITH 64K GOES UNUSED (48K
WORTH) UNLESS PROGRAMS LIKE ┬ASIC-8 ETC, TAKE ADVANTAGE OF IT. ╘HERE ARE VARIOUS
MOD FILES DESCRIBING THE UPGRADE FROM 16K TO 64K AND IT IS _STRONGLY_ ADVISED
(ALTHOUGH THE AUTHOR HAS NOT YET DONE SO) AND BE AWARE THAT ***╧╨┼╬╔╬╟ ┘╧╒╥
├╧═╨╒╘┼╥ ╩╒╙╘ ╘╧ ╠╧╧╦, ┘╧╒ ═┴┘ ═┼╙╙ ╔╘ ╒╨*** AND IT IS _STRONGLY_ ADVISED THAT
YOU CONTACT A PERSON EXPERIENCED WITH ELECTRONICS TO PERFORM THE UPGRADE FOR
YOU. ╬OTE ALSO THAT SOME MAIL ORDER COMPANIES ARE OFFERING AN "UP-GRADE BOARD"
WHICH PLUGS INTO THE 8563 SLOT AND DOES NOT INVOLVE DISAUDERING THE ╥┴═ CHIPS.
╬OW, THE 8563 USES THE 16K OF MEMORY (IT IGNORES THE EXTRA 48K OF MEMORY WHEN
IT'S GOT 64K, THUS THE FOLLOWING APPLIES ALSO TO THE 8563'S EQUIPPED WITH 64K
OF MEMORY) AND NORMALLY, HAS THE FOLLOWING MEMORY MAP:
$0000 - $07FF - ╙CREEN ═EMORY
$0800 - $0FFF - ┴TTRIBUTE ═EMORY
$1000 - $1FFF - ╒NUSED
$2000 - $2FFF - ╒PPER├ASE / ╟RAPHIC ├HARACTER ╙ET (├HAR ╙ET #1)
$3000 - $3FFF - ╠OWER├ASE / ╒PPER├ASE ├HARACTER ╙ET (├HAR ╙ET #2)
+---------------------------+
▄ ╫RITING TO 8563 ╥EGISTERS ▄
+---------------------------+
╬OW HOW DO WE WRITE TO THESE REGISTERS WE'VE LEARNED SO MUCH ABOUT? ╘HERE'S
SEVERAL WAYS DEPENDING ON HOW LAZY YOU ARE. ╘HE PURE-ML VERSION:
╫╥╔╘╔╬╟ ╘╧ ┴ ╥┼╟╔╙╘┼╥:
WRITEREG = * ; THIS ROUTINE WRITES .A TO REGISTER # .X, ┴SSSUMES ╔/╧ BLOCK IN
STX $D600
- LDX $D600
BPL -
STA $D601
RTS
ALSO, IN BANK 15 THERE IS A SIMILAIR ROUTINE AT $CDCC. ├ALLING IT AT $CDCA
LOADS .X WITH A VALUE OF 31 INDICATING THE DATA REGISTER WHICH IS OFTEN USEFUL.
╞ROM BASIC, JUST USE A ╙┘╙ 52684, VALUE, REGISTER#
╥┼┴─╔╬╟ ╞╥╧═ ┴ ╥┼╟╔╙╘┼╥:
READREG = * ; THIS ROUTINE RETURNS THE CONTENTS OF REGISTER # .X IN .A
; ┴SSUMES ╔/╧ BLOCK SWITCHED IN
STX $D600
- LDX $D600
BPL -
LDA $D601
OR USE THE ROUTINE IN BANK 15 AT $CDDA. ╞ROM BASIC, A ╙┘╙ 52698,,REGISTER#
AND THEN A ╥╥┼╟ ┴ RETURNS THE VALUE IN VARIABLE ┴.
+--------------------+
▄ ╞URTHER 8563 ╬OTES ▄
+--------------------+
═ANY ├=128 OWNERS ARE STILL USING THEIR MONITORS THEY HAD WHEN THEY HAD THEIR
├=64'S AND ARE ABLE TO USE THE 80 COLUMN SCREEN THROUGH A "CONVERTER-CABLE"
(BASICALLY TAKING PIN 7 OF THE ╥╟┬╔ PORT AND FEEDING IT AS RAW VIDEO). ╘HERE
IS ALSO A TEXT FILE OUT EXPLAINING HOW TO TAKE THE ╥,╟,┬,╔ PINS ON THAT PORT
TO DISPLAY SHADES OF GRAY ON A MONOCHROME MONITOR (BASICALLY TYING RESISTORS
WITH DIODES ACROSS EACH COLOR PIN AND THEN JOINING THEM). ╘HERE IS RELIEF!! :-)
╘HE 8563 IS A CHIP FULL OF CABIBILITIES WAITING TO BE FOUND AND DEVELOPED. ╔'D
BE INTERESTED IN SEEING ANY CODE / TECHNIQUES THAT READERS OF THIS NET-MAG HAVE
FOUND. ╟IVEN THAT ENOUGH ARE SUBMITTED, A POSSIBLE LISTING OF SOME OF THE
BETTER TRICKS AND TECHNIQUES MIGHT BE POSSIBLE IN THE FUTURE.
===========================================================================
╞╔╠┼ ╙╨╠╔╘╘┼╥ - ═ARK ╠AWRENCE 9152427D@LEVELS.UNISA.EDU.AU
=============
╘HIS PROGRAM STEMMED FROM THE INABILITY OF ╪╠╔╬╦ TO TRANSFER ├╙-─╧╙ FROM MY PC
TO MY 128. ╪╠╔╬╦ TRANSFERS ABOUT 43╦ (╔ THINK), WHEREAS ├╙-─╧╙ WAS ABOUT 48╦.
╥ATHER THAN DO THE WHOLE THING AT ONCE, WHY NOT CUT THE JOB UP INTO MORE
SIZEABLE PIECES, TRANSFER THE PROGRAM PIECE BY PIECE, AND THEN REASSEMBLE THE
PIECES AT THE OTHER END?
┴ND SO EVENTUATED THE BIRTH OF ╙╨╠╔╘ :-)
╙╨╠╔╘, WRITTEN ENTIRELY IN ╘URBO ╨ASCAL, ALLOWS YOU TO SPLIT ─╧╙ FILES INTO
SMALLER PIECES - YOU CAN EITHER TELL IT A SIZE TO SPLIT THE FILES INTO, OR
TELL IT A NUMBER OF FILES TO CREATE. ┘OU THEN GIVE ╙╨╠╔╘ THE BASE FILENAME
FOR THE NEW FILES ╫╔╘╚ ╬╧ ┼╪╘┼╬╙╔╧╬ - ╙╨╠╔╘ WILL GIVE THE NEW FILES THEIR OWN
EXTENSIONS, AND ╙╨╠╔╘ WILL THEN CREATE THESE FILES TO YOUR LIKING.
╩UST TRANSFER THE FOLLOWING PROGRAM TO ╘URBO, COMPILE IT, AND AWAY YOU GO!!!
╚OPEFULLY, THE PROGRAM IS COMMENTED ENOUGH TO GIVE YOU A FAIR IDEA OF WHAT'S
GOING ON - ALTHOUGH IT ISN'T AT ALL COMPLICATED TO UNDERSTAND.
┴T SOME POINTS ╔ HAVE COMMENTS THAT SEEM THE LEAST IMPORTANT - ┼╬─ █ ├┴╙┼ ▌ -
THEY ARE TO HELP ME WHEN ╔ PROGRAM... ╔ FIND IT EASY TO LOSE TRACK OF WHICH
┼╬─ IS FOR WHAT, STUFF UP MY INDENTATION, LOST BITS AND PIECES, DELETE THE
WRONG PARTS, ETC, ETC.
╔ FOUND IT HELPED ME, SO IT MAY HELP OTHERS.
╔F YOU NEED ANY FURTHER EXPLANATION, JUST LET ME KNOW :-)
┴NOTHER INTERESTING THING ╔ DISCOVERED ABOUT ╪╠╔╬╦. ╔T DOESN'T TRANSFER THE
FILES TO THE CORRECT SIZE. ╔ THINK (HAVEN'T HAD TIME TO SIT DOWN AND CHECK
IT OUT YET) IT TRANSFERS TO THE NEAREST 256, 512 OR 1024 BYTE BOUNDARY. ╔F
YOUR FILE DOESN'T REACH THE BOUNDARY, IT WILL PAD THE REST OUT WITH ZEROES
╔ THINK. ╙O, WHEN YOU GO TO REASSEMBLE THE FILE, IT'S GOT ALL THIS GARBAGE
IN PLACES WHERE IT SHOULDN'T BE, AND THE THING WON'T WORK.
╙O, WHEN ╙╨╠╔╘TING A FILE, SPECIFY THE SIZE TO A MULTIPLE OF ONE OF THESE
BOUNDARIES.
╘HEN, USING A M/C MONITOR, LOAD ALL THE PARTS IN TOGETHER.
╔'LL TRY TO SET ASIDE A LITTLE TIME IN THE NOT TOO DISTANT FUTURE TO WRITE A
M/C PROGRAM TO JOIN THE PARTS FOR YOU, SINCE IT CAN GET CONFUSING REASSEMBLING
THE PARTS BY HAND, AND THE BUILT IN DOS COPY THAT COMMODORE SO KINDLY GRACED US
WITH IS SO DARNED FAST <COUGH> <COUGH> :-)
[┼D. ╬OTE: ╫HILE THE DOS COPY COMMAND IS SLOW.... FOR THOSE OF YOU WHO ARE
IMPATIENT TRY USING SOMETHINE LIKE THE FOLLOWING TO JOIN FILES TOGATHER MAKING
SURE THAT THERE'S ENOUGH SPACE ON THE DISK:
OPEN15,8,15,"C0:NAME=NAME1,NAME2...": CLOSE15]
╙O, GOOD LUCK AND ENJOY!
---------------------------------------------------------------------------
╨ROGRAM ╙PLIT (INPUT,OUTPUT);
╒SES ─OS;
█ USES SPECIFIC FILE HANDLING ROUTINES ▌
╓AR
╔N╞ILE,╧UTFILE : ╞ILE OF ┬YTE;
├OUNT,╬UMBER,╙IZE,╬EW╙IZE,
╠AST,├OUNTER : ╠ONGINT;
╔N╞ILE╬AME,╬EWFILE,╧UT╞ILE╬AME: ╙TRING;
╙,╨ : ╨ATH╙TR;
─ : ─IR╙TR;
╬ : ╬AME╙TR;
┼ : ┼XT╙TR;
╙PLIT╘YPE,├HECK : ├HAR;
─ATA : ┬YTE;
┼XTENSION : ╙TRING[3];
┬EGIN
╞OR COUNT := 1 TO 25 DO
╫RITELN;
█ ─UMB WAY TO CLEAR THE SCREEN :-) ▌
╫RITELN ('*********************************************************');
╫RITELN ('* ╞╔╠┼ ╙╨╠╔╘╘╔╬╟ ╒╘╔╠╔╘┘ ╓0.01 (├) 1992 ═┴╥╦ ╠┴╫╥┼╬├┼ *');
╫RITELN ('* (-: ═┴─┼ ╔╬ ┴╒╙╘╥┴╠╔┴ :-) *');
╫RITELN ('*********************************************************');
╫RITELN;
╫RITE ('┼NTER ╞ILENAME (INCLUDING DRIVE AND PATH) ');
╥EAD╠N (╔N╞ILE╬AME);
╫RITELN;
╞OR COUNT := 1 TO LENGTH (╔N╞ILE╬AME) DO
╔N╞ILE╬AME[COUNT] := ╒P├ASE ( ╔N╞ILE╬AME[COUNT] );
█ CHANGE FILENAME TO ALL UPPERCASE CHARACTERS ▌
╞╙PLIT(╔N╞ILE╬AME,D,N,E);
█ SPLIT FILENAME INTO IT'S RESPECTIVE PARTS:
D - ─IRECTORY
N - ╬AME
E - ┼XTENSION ▌
╙ := ╞╙EARCH(╔N╞ILE╬AME,╟ET┼NV(─));
█ SEARCH FOR FILE ╞╔╠┼╬┴═┼ IN DIRECTORY ─ ▌
IF ╙ = '' THEN
WRITELN ('*┼╥╥╧╥* ╞ILE "',╔N╞ILE╬AME,'" NOT FOUND.')
█ ╙ EQUALS '' (NOTHING) IF ╞╔╠┼╬┴═┼ DOESN'T EXIST ▌
┼LSE
┬EGIN
┴SSIGN (╔NFILE,╔N╞ILE╬AME);
╥ESET (╔NFILE);
█ ╧PEN THE ╔NPUT ╞ILE ▌
╙IZE := ╞ILE╙IZE (╔N╞ILE);
█ ╟ET FILE SIZE ▌
╫RITELN ('╞ILE╬AME: ',╔N╞ILE╬AME);
╫RITELN ('╞ILE╙IZE: ',╙IZE,' ┬YTES.');
╫RITELN;
█ ╙HOW FILE INFO ▌
╫RITELN ('╔N WHICH WAY WOULD YOU LIKE THE FILE SPLIT?');
╫RITELN (' (A) ╬UMBER OF ┬YTES.');
╫RITELN (' (B) ╬UMBER OF ╞ILES.');
╥EPEAT
╫RITE ('┼NTER YOUR SELECTION ');
╥EADLN (╙PLIT╘YPE);
╙PLIT╘YPE := ╒P├ASE(╙PLIT╘YPE);
╒NTIL (╙PLIT╘YPE >= '┴') AND (╙PLIT╘YPE <= '┬');
█ LET USER CHOOSE WHICH WAY TO SPLIT FILE ▌
╫RITELN;
├ASE ╙PLIT╘YPE OF
'┴': ┬EGIN
█ SPLIT BY NUMBER OF BYTES ▌
╫RITE ('┼NTER BYTE SIZE OF NEW FILES ');
╥EADLN (╬EW╙IZE);
╫RITELN;
╔F (╬EW╙IZE > ╙IZE) THEN
╫RITELN ('╚EY - ┼VEN ╔ CAN''T DO THAT!!!')
┼LSE
BEGIN
╬UMBER := ╙IZE DIV ╬EW╙IZE;
╠AST := ╙IZE - ╬UMBER * ╬EW╙IZE;
╬UMBER := ╬UMBER + 1;
╫RITE ('┼NTER ┬ASE ╞ILENAME (INCLUDING DRIVE AND PATH) ');
╥EADLN (╬EW╞ILE);
╫RITELN;
╫RITELN ('├REATING ',╬UMBER,' NEW FILES...');
┼ND;
┼ND; █ ┴ ▌
'┬': ┬EGIN
█ ╙PLIT BY FILE SIZE ▌
╫RITE ('┼NTER NUMBER OF NEW FILES: ');
╥EADLN(╬UMBER);
╫RITELN;
╬EW╙IZE := ╙IZE DIV ╬UMBER + 1;
╠AST := ╙IZE - (╬UMBER - 1) * ╬EWSIZE;
╬UMBER := ╬UMBER;
╫RITE ('┼NTER ┬ASE ╞ILENAME (INCLUDING DRIVE AND PATH) ');
╥EADLN (╬EW╞ILE);
╫RITELN;
╫RITELN ('├REATING ',╬UMBER,' NEW FILES...');
┼ND; █ ┬ ▌
┼ND; █ ├ASE ▌
╫RITELN;
╞OR ├OUNT := 1 TO ╬UMBER DO
█ ╬╒═┬┼╥ NEW FILES WILL BE CREATED ▌
┬EGIN
╔F ├OUNT = ╬UMBER THEN
╬EW╙IZE := ╠AST;
█ ═ORE OFTEN THAN NOT, THE FILES WON'T DIVIDE EVENLY FROM THE
ORIGINAL. ╙O, THE LAST FILE WILL BE SMALLER THAN THE REST.
┬ECAUSE OF THIS, ╔ PREVIOUSLY CALCULATED THE SIZE OF THE FINAL
FILE, AND HERE CHECK IF WE'RE UP TO THE LAST PART YET - AND IF
WE ARE, ╔ SET THE SIZE OF THE LAST FILE ACCORDINGLY ▌
╙TR(├OUNT,┼XTENSION);
█ ═AKE ┼╪╘┼╬╙╔╧╬ A STRING REPRESENTATION OF ├╧╒╬╘, TO BE ADDED TO
THE ╧UT╞ILE╬AME TO MAKE THINGS A TAD EASIER ▌
╧UT╞ILE╬AME := ├ONCAT(╬EW╞ILE,'.',├OPY('00',1,3-╠ENGTH(┼XTENSION)),┼
█ ├REATE FILENAME BASED ON WHICH PART WE'RE UP TO ▌
┴SSIGN (╧UT╞ILE,╧UT╞ILE╬AME);
╥EWRITE (╧UTFILE);
█ ╧PEN EACH ╧UTPUT ╞ILE ▌
╫RITE ('├REATING ',╧UT╞ILE╬AME,'... ');
╞OR ├OUNTER := 1 TO ╬EW╙IZE DO
█ ╫RITE TO EACH ╧UTPUT ╞ILE ▌
┬EGIN
╥EAD (╔NFILE,─ATA);
╫RITE (╧UT╞ILE,─ATA);
█ ╘RANSFER DATA FROM INPUT FILE TO OUTPUT FILE ▌
┼ND;
├LOSE (╧UTFILE);
█ ├LOSE EACH ╧UTPUT ╞ILE ▌
╫RITELN ('─ONE!');